Networks interconnect hosts using a variety of network devices, including host network adapters, routers, switches and hubs, each of which include network interfaces for interconnecting the various devices via cables and fibers. Applications send data over a network by submitting it to an operating system, after which it becomes network traffic. Network devices generally use a combination of hardware and software to forward network traffic from one network interface to another. Each interface can send and receive network traffic at a finite rate, and if the rate at which traffic is directed to a network interface exceeds the rate at which the network interface can forward the traffic onward, congestion occurs. Network devices may handle this condition by queuing traffic in the device's memory until the congestion subsides. In other cases, network equipment may discard some excess traffic to alleviate congestion.
As a result, applications sending network data experience varying latency or traffic loss. Applications generate traffic at varying rates and generally require that the network be able to carry traffic at the rate at which they generate it. In addition, applications differ in how tolerant they are of traffic delays in the network, and of variation in traffic delay. For example, certain applications can tolerate some degree of traffic loss, while others cannot. As a result, different applications have different requirements regarding the handling of their traffic in the network.
Network Quality of Service (QoS) refers to the ability of the network to handle network traffic such that it meets the service needs of certain applications. To this end, network QoS requires fundamental traffic handling mechanisms in the network, the ability to identify traffic that is entitled to these mechanisms and the ability to control these mechanisms. The fundamental traffic handling mechanisms that comprise a QoS enabled network include the capacity of interfaces to forward traffic, the memory available to store traffic in network devices, (until it can be forwarded), and mechanisms internal to network devices that determine which traffic gets preferential access to these resources. The requirements of applications for handling of their traffic are expressed using the QoS related parameters of bandwidth—the rate at which an application's traffic must be carried by the network; latency—the delay that an application can tolerate in delivering a packet of data; jitter—the variation in latency; and loss—the percentage of lost data.
Because network resources are finite, there are parts of the network wherein resources are unable to meet demand. QoS mechanisms work by controlling the allocation of network resources to application traffic in a manner that meets the application's service requirements. Devices that provide QoS support do so by intelligently allocating resources to submitted traffic. For example, under congestion, a network device might choose to queue traffic of applications that are more latency tolerant (or did not specify their latency tolerance to the network) instead of traffic of applications that are less latency tolerant. As a result, the traffic of applications that are less latency tolerant can be forwarded immediately to the next network device. In this example, interface capacity is a resource which is granted to the latency-intolerant traffic, while device memory is a resource that has been granted to the latency-tolerant traffic.
In order to allot resources preferentially to certain traffic, it is necessary to identify different traffic and to associate it with the resources it requires. This is accomplished by recognizing separate traffic flows within the network and by defining traffic handling parameters which apply to these flows. Devices identify packets as belonging to one flow or another. In order to invoke QoS mechanisms, it is necessary to communicate to network devices the information necessary to associate packets with flows, and a description of the handling that should apply to traffic on each flow. This is achieved through various signaling means and device configuration.
One QoS signaling protocol is RSVP (Resource Reservation Protocol), which works over TCP/IP. RSVP applications can use RSVP messages to request quality of service from the network and to indicate QoS requirements to the network and to peer applications. RSVP is suited for use with IP (Internet Protocol) traffic. As currently defined, RSVP uses Integrated Services (Intserv) semantics to convey its QoS requirements to the network. Since RSVP operates at a layer above TCP/IP, it is largely independent of the various underlying network media over which it operates. Therefore, RSVP can be considered an abstraction layer between applications (or the operating system) and media-specific QoS mechanisms.
RSVP messages follow the path of the traffic for which resources are being requested, whereby messages arrive at the devices whose resources will be utilized by a successful reservation, i.e., by admission of a flow. This provides admission control based on the current resources available in the affected devices, that is, RSVP-aware devices understand the applicability of RSVP requests to their specific media, and are able to accept or reject the messages based on their resources and ability to support the requests. This end-to-end nature of admission control contrasts with top-down QoS mechanisms, which assign resources (or admit flows) based on statistics and heuristics of anticipated traffic paths.
Standard RSVP messages typically carry a quantitative description of the relevant QoS traffic in parameters referred to as token-bucket parameters (in Intserv semantics). Traffic generated by multimedia applications can easily be quantified in this manner. Another aspect of RSVP is that it is oriented towards relatively long-lived flows, as RSVP effectively signals to set up a ‘circuit’ between sender and receiver. There is inherent overhead in this process, and as a result, RSVP is better suited for ‘session-oriented’ applications that exchange QoS data between fixed endpoints, and less suited for applications that exchange bursts of data between frequently changing endpoints (such as web browsing). Thus, for example, RSVP, using the standard token-bucket model of Intserv, is well suited to multimedia applications such as IP telephony and video serving, which tend to generate relatively long-lived flows with easily quantifiable traffic patterns.
However, standard RSVP/Intserv is not suitable for other types of applications that are unable to quantify the resources they require from the network. Such “qualitative applications” include, for example, ERP or database applications, such as SAP, SQL server accesses and transaction processing applications. Such applications tend to generate sporadic bursts of traffic that are difficult to quantify in a manner that is useful for admission control. Since the required resources cannot be quantified, network nodes cannot determine whether sufficient resources exist to accommodate an application's traffic and standard Intserv style admission control cannot be applied. As a result, such programs cannot benefit from the existing QoS mechanisms that are centered on quantitative-based parameters.